Audio based human-interaction proof

ABSTRACT

A method and system for allowing access to computer functions such as websites that utilizes a user&#39;s ability to recognize sounds is described. The method presents a user a series of sounds. Some of the sounds presented in the series are labeled as validation sounds. The user is asked to provide an input every time he or she hears the validation sound. The user must identify the sound within a specified length of time. The system disclosed comprises a user interface, a sound database module, a generation module, and a sound database module. The generation module creates the validation test file and expected answer. The answer confirmation module checks the input from the requesting computer and provides access to the computer function if the computer input from the requesting computer meets the required parameters.

CROSREFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 13/308,011 filed on Nov. 30, 2011, which claims priority under35 U.S.C. §119 to U.S. Provisional Application Ser. No. 61/418,025 filedon Nov. 30, 2010, entitled “Audio Based Universally Usable HumanInteraction Proof,” which is incorporated herein by reference in itsentirety.

BACKGROUND

1. Field of the Invention

The present invention relates to the field of data processing andinformation security. More specifically, the invention relates to amethod for allowing visually impaired individuals to access securedwebsites or computer functions designed to require a human person toenter information and, at the same time, prevent automated systems toaccess the website or computer function.

2. Background

Current audio based Completely Automated Public Turing Test to TellComputers and Humans Apart (“CAPTCHA”) challenges are difficult toanswer correctly. Users are played a sound bite of recorded butdistorted speech and asked to type in what the user heard. The existingaudio CAPTCHA validation tests are difficult to use and have a very lowsuccess rate. For example, it has been reported that the most popularversion of audio validation tests (i.e., GOOGLE's reCAPTCHA) has a usersuccess rate of no more than 46%. Because audio based CAPTCHAs are theonly viable alternative for visually impaired users, and CAPTCHAchallenges are used to protect many commercial websites, the difficultuse and low success rate for visually impaired users represent asignificant problem for that user community.

In addition, the sound bites for some audio CAPTCHAs are drawn fromrecordings of old radio broadcasts (e.g., GREEN HORNET, THE LONE RANGER,etc.) and are in English. There is no corresponding large base of audiomaterial in other languages, limiting the usefulness of currentlyavailable audio CAPTCHAs. Furthermore, the standard visual based CAPTCHAchallenges are susceptible to being solved by computers using variousforms of analysis. Research has found that the challenges can be solvedby computers 20% to 30% of the time.

SUMARY OF THE INVENTION

Disclosed is a system and method for authorizing access to a computerfunction, such as a website, utilizing a sound validation test. In afirst step of the method, an application receives a request to access acomputer function from a requesting computer. A validation test file isgenerated that includes both a series of sounds presented at variousintervals and an expected response. At least one of the sounds in theseries of sounds is a validation sound. The validation test is thenpresented to the requesting computer. In a further step, an input fromthe requesting computer is collected. The input from the requestingcomputer and the expected response are then compared to determinewhether the two match. If the input matches the expected response, therequesting computer is allowed access to the computer function.

A system in accordance with one embodiment of the present invention isalso described in which the system comprises a user interface, avalidation test generation module, an answer confirmation module, and asound database module. The system is preferably connected to therequesting computers through a computer network. The user interface inthe system may be configured to manage the communications between therequesting computer and the system's modules.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features, aspects, and advantages of the presentinvention are considered in more detail in relation to the followingdescription of embodiments thereof shown in the accompanying drawings,in which:

FIG. 1 is a flowchart illustrating a computer implemented method toauthorize access to a computer function in accordance with certainaspects of a preferred embodiment of the present invention.

FIG. 2 is a flowchart illustrating a method for generating a validationtest in accordance with further aspects of a preferred embodiment of thepresent invention.

FIG. 3 is a flowchart illustrating the input recognition sequence forthe validation test in accordance with still further aspects of anembodiment of the present invention.

FIG. 4 is a graphical representation of a system suitable for use withthe methods of FIGS. 1-3.

DETAILED DESCRIPTION

The invention summarized above may be better understood by referring tothe following description and claims, which should be read inconjunction with the accompanying drawings in which like referencenumerals are used for like parts and steps. The following description isof a particular embodiment of the invention, set out to enable one topractice an implementation of the invention, and is not intended tolimit the preferred embodiment, but to serve as a particular examplethereof. Those skilled in the art should appreciate that they mayreadily use the conception and specific embodiments disclosed as a basisfor modifying or designing other methods and systems for carrying outthe same purposes of the present invention. Those skilled in the artshould also realize that such equivalent assemblies do not depart fromthe spirit and scope of the invention in its broadest form.

Disclosed is a computer-implemented system and method that presentsCAPTCHA challenges in a real-time format. This allows the development ofa usable audio based CAPTHCA challenge or validation test. The real-timepresentation allows a simple audio based task with a high success ratewhile complicating the use of established methods used to circumventCAPTCHA challenges by denying the intruders the time needed to analyzethe task.

In accordance with a particularly preferred embodiment, a computerimplemented method to authorize access to a computer function is shownin FIG. 1. In step 101, an application managing access to the computerfunction receives a request to access the computer function from arequesting computer. The application managing access to the computerfunction is a computer program or a computer configured to carry out themethod for authorizing access to a computer function as describedherein. As used in this description, a computer function means any typeof computer process. Some examples of computer functions include accessto a particular website, access to a mobile device, access to a computerprogram, access to a processor, execution of a particular program or anyother type of action that a user may require a computer to conduct. Itis contemplated that the application managing access to the computerfunction may run on the computer where the function is to be conductedor a remote computer. The requesting computer and the applicationmanaging access to the computer function may be on the same machine ormerely different applications within the same structure or separatecomputers all together.

At step 107, the application managing access to the computer functiongenerates a validation test and an expected response. In one preferredembodiment, the validation test and expected response are generated asexplained in more detail below in association with FIG. 2. Thevalidation test comprises a series of sounds presented at variousintervals. At least one sound in the series of sounds is a validationsound (which is also referred to herein as the “target sound”). When auser hears the validation sound, he or she can strike a key on akeyboard or touch a screen to signal that the user has heard the sound.In a further exemplary embodiment, the validation test is thirty fourseconds in length. The validation test is comprised of 10 individualsound spots each separated by a brief period of silence and an audiodelimiter in the form or a spoken phrase, such as “next sound”. Thisparticular embodiment, allows the user to decide whether one specificsound spot corresponds to the target sound or not. The delimiter promptsthe user to listen for the sound and make a decision. In somealternative embodiments, no delimiter is provided and the user providesan input when the user hears the target sound.

In one exemplary non-limiting example, each sound bite is 3 seconds inlength. It comprises the sound and a period of silence, which combinedlast 2 seconds and the delimiter lasts 1 second. The total ten soundslast 30 seconds. The generation of the validation test and evaluation ofthe responses takes 4 seconds for a total of 34 seconds. The validationtest requires that the entire 30 seconds be played, reducing the risk ofintrusion by BOTs or human interaction. It is contemplated that thenumber of sound spots, length of each spot, and total length of thevalidation test can be adapted to the requirements of the computerfunction being protected, and the level of security desired by theadministrator of the computer function.

At step 113, the validation test is presented to the requestingcomputer. In some embodiments, the validation test is executed at therequesting computer. Alternatively, the validation test may be executedat computer hosting the application managing access to the computerfunction and only the test sounds are transmitted to the requestingcomputer for identification by the user.

Once the requesting computer presents a user with the validation test,the requesting computer receives the responses to the validation testand transmits the validation responses to the application managingaccess to the computer function at step 119. As explained above, incertain embodiments the input consists of the user pressing a key on akeyboard. In one preferred embodiment, the key is any key on thekeyboard. In other embodiments, the key input is a specific key on thekeyboard such as a space key or the enter key. In yet a furtherembodiment of the present invention, the input is a click of a mouse orthe touch signal from a touchscreen in a mobile device, tablet computer,or any other type of input that the user utilizes to indicate to therequesting computer that the user has identified a validation sound.

After the input has been collected from the user, the requestingcomputer transmits the input to the application managing access to thecomputer function and the application determines whether the inputmatches the expected response in step 125. The expected responsecorresponds to a number of inputs within specified time periods based onthe number of validation sounds presented in the validation test. If theinput matches the expected response, the application allows access tothe computer function in step 131. If the input does not match theexpected response, the application managing access denies further accessto the computer function in step 137.

In one exemplary embodiment, the above method is provided when a user ofa website, which in this case is the computer function, wishes to accessan area of the site that the website operator intends to keep from beingaccessed by BOTs or other automated website penetration tools. Beforebeing allowed into such website, the user is given a validation testthat asks the user to identify a given sound in a series of sounds. Ascreen is preferably initially presented to the user that explains thechallenge and instructs the user to press the space bar or any otherdesignated key each time the user hears a target sound. For example, theuser is asked to press a key each time he or she hears the sound of abell ringing. The user is then instructed to click on a button (or pressthe space bar) to begin the validation test or challenge. In oneexemplary embodiment, a series of sounds is presented to the user, some(varying) number of which would be the target or validation sound of abell or other sound easily recognizable by the user. The user then hasthe opportunity to respond (e.g., press a key, etc.) each time the userhears the target sound and be allowed to enter the website if the usercorrectly identifies all of the target sounds. Because this methodeliminates the need for text entry, and is essentially language andliteracy independent, it significantly simplifies the task for theresponder. It also eliminates the need for evaluating responses againsta list of equivalent terms (e.g., dog=puppy=pooch=hound, etc.).

The validation test is generated as shown in FIG. 2, in accordance withfurther aspects of an embodiment of the invention. More particularly,the validation test (or challenge) presented to a user comprisespreferably a low resolution audio file, preferably in MP3 format. Aperson of ordinary skill in the art, however, will appreciate that otheraudio formats can be used for the validation. The method for creating avalidation test begins at step 201 where an application managing accessto the computer function selects an answer category from a database ofsounds arranged by categories. There may be numerous entries or soundsin each category. Categories preferably include sounds like “bells,”“dog barks,” “babies crying,” and other distinctive sounds that a useris able to easily recognize In order to generate a challenge orvalidation file, the application selects a type of sound that will bethe target or validation sound from the selected category. For example,the application may select a sound labeled “bells” that the user isasked to identify. The application then, in step 207, preferablyrandomly sets a number of target positions for the audio file,preferably between 2 and 4. Optionally, the number of positions may bepredetermined instead of randomly selected. It is contemplated that theapplication may select as many spots as required for securedauthentication. A person of ordinary skill in the art would recognizethat an increased number of spots results in increased security, butalso an increase in the demand on resources in the system and anincrease in the required interaction with the user.

In the next step 214, the application selects the validation sounds fromthe selected answer category. The application may select one sound fromthe category to be used one or more times as a validation sound or,alternatively, the application may select various sounds within thecategory to fill the validation spots. For example, where the validationsound is a bell, the application may select one particular bell sound tobe used in the various spots. Alternatively, the application may selectvarious different types of bell sounds as the validation sound. Theapplication at step 221 preferably randomly assigns audio clips from thetarget category to the target positions in the audio file.

Each category of validation sounds preferably has an associated list ofappropriate categories from which to draw decoy sounds (also referred toherein as non-validation sounds). The list of appropriate sounds and itscorrelation with the validation sound selected ensures that the decoysounds are not too similar to the target sounds, which could causeconfusion to the user. In addition, logic is implemented to ensure thatthe target category is not the only category in the audio file with morethan one position. At step 228, the application determines theappropriate decoy sounds to be used in association with the validationsounds. The application is programmed to ensure that the decoy soundsare sufficiently different from the validation sounds as to avoid userconfusion. For example, the application may be programmed to ensure thata bell sound does not conflict with a hammer banging on metal sound. Theapplication then selects the decoy sounds to be utilized in thevalidation test. At step 234 the decoy sounds are assigned to theremaining positions in the audio file, i.e., those positions notassigned to a validation sound.

The application may also obtain additional validation sounds from othercategories not previously selected and assigns them to any unfilledpositions in step 240. Last, at step 247 the application preferablymerges all of the selected sound clips into a single file, e.g., an MP3file that is played at the requesting computer or browser. It iscontemplated that the audio file can be in any format that allows thefile to be played on a computer or electronic device in association withthe validation test described in herein. The validation test file(comprising the target or validation sounds and decoy sounds) may beproduced on demand from a database of individual audio clips.

The audio file is preferably 30 seconds in length, conceptually dividedinto 10 2.5 second segments, although alternative sound segment lengthsmay likewise be employed without departing from the spirit and scope ofthe invention. Each segment preferably contains a two second audio clipand a half second of silence. Preferably between two and four of thepositions contain target sounds and the rest of the positions are filledwith decoy sounds. It is contemplated that in some embodiments, thelength of time for each sound varies.

Further aspects of a method for authorizing access to a computerfunction in accordance with an embodiment of the invention are shown inthe flow chart of FIG. 3. In step 301 the computer function, such as awebsite, is presented to a user by a requesting computer. The user thenrequests access to the computer function by clicking on a particularportion of the screen presented by the requesting computer or selectinga particular option presented to a visually impaired individual. Theapplication records an input, such as a click on a particular screen orthe use of a particular key or mouse input. After the applicationreceives the input it determines whether that is the first input inresponse to a request to authorize access at step 307. If it is thefirst time the input has been registered, the application records thatparticular input as the first input to start the time sequence for theauthorization validation test. The application at step 321 generates asound file containing the validation test. In step 334 the validationtest is recorded on a validation database. In one particular embodiment,the file name of the sound file is presented to the browser being usedto request access at step 327, and at step 341 the audio file isconstructed and played on the browser for the individual user toidentify the validation sounds produced in the recording. At step 347the application sets the timer that is utilized to validate the answersto the authorization validation test.

At step 361 the application determines whether the expected time hasexpired. If the time has not expired, the application goes back to step301 and determines if an input has been received. If the input has beenreceived the application checks whether it is the first input at step307. If it is not the first input, the application records the timeposition for that particular input at step 354. Again the applicationdetermines whether the time has expired at step 361. If the time has notexpired, the cycle continues until the time expires. Once the time forinput expires, the times of the inputs are submitted for processing atstep 367. The answers are then processed at step 371 where the times atwhich the inputs were made is compared with the times expected inaccordance with the generated sound recording. The application then atstep 377 evaluates whether the access should be granted. If the inputsare valid, then at step 387 the requesting computer is allowed access tothe computer function. For example, the secured website is displayed onthe requesting computer's browser.

If the inputs do not meet the expected results, at step 381 a failurenotification is displayed on the requesting computer and the system isreset at step 397. In alternative embodiments, the failure notificationincludes an audio message that alerts a visually impaired user that thetest has failed. At that point the application develops a new answer setin step 304 and the new validation test is presented to the requestingcomputer. Similarly, if no input is received at step 391 the applicationdetermines if the timer has expired. If it has not expired, the testwill continue to step 301. If the time has expired without input, thesystem is reset at step 397 and a new validation is presented in step304.

When the user initiates the challenge, a series of a fixed number ofrecorded sounds (e.g., ten sounds), each of relatively short duration(e.g., two seconds in length) with a smaller break in between each ofthe record sounds (e.g., one half of a second in length), are played forthe user. Between one and four of the sounds are examples of the targetsound, e.g., a bell. In order to successfully pass the challenge, theuser must press the space bar (or other designated key) in response tothe target sounds. The application records the timing of the key pressesand, when the sound series is complete, submits the response to theserver for analysis. The application preferably examines the timing ofthe key presses and determines if the key press occurred while thetarget sound was playing. If there is a single key press recorded foreach and every instance of the target sound, the application considersthe challenge to be correctly answered and sends a tokenized response tothe web server that then allows the user to proceed into the website.

In some preferred embodiments of the present invention, the applicationis preferably configured to not accept a response that has not allowedenough time (e.g., 24 seconds) for the sound series to play completely,under the assumption that this is a guess rather than a real response.This serves as a deterrent to distributed “brute force” attacks becausean automated process would have no significant speed advantage over anindividual user. The application will also preferably reject anyresponse that takes more than the allotted time. This denies intrudersthe ability to proxy the challenge to a human to solve on behalf of theBOT. Because massive (i.e., brute force) guessing and proxy are the mostwidely used techniques for circumventing CAPTCHAs, these benefits of thereal-time approach used by the system and method described herein aresignificant.

With regard to still further aspects of an embodiment of the presentinvention, a system for authorizing access to a computer function isprovided as shown on FIG. 4. An exemplary computer network configurationsuitable for implementing the computer implemented method to authorizeaccess to a computer function is described herein. It is noted, however,that such system is exemplary only, and that the components, processsteps, and/or data structures may be implemented using various types ofoperating systems, computing platforms, computer programs, and/orgeneral purpose machines. In addition, those of ordinary skill in theart will recognize that devices of a less general purpose nature, suchas hardwire devices, field programmable gate arrays, applicationspecific integrated circuits, or the like, may also be used withoutdeparting from the spirit and scope of the present invention.

The system 414 for implementing a computer implemented method toauthorize access to a computer function is connected to one or more userclient devices 401 (requesting computers) through a computer network407, such as a wide area network (e.g., the Internet). The system 414 isconfigured to generate validation tests based on validation sounds. Thevalidation test allows a requesting computer 401 to access a computerfunction, e.g., a website, based on the response from a user utilizingthe requesting computer 401.

In one preferred embodiment, the system 414 includes a user interfacemodule 427, a validation test generation module 427, an answerconfirmation module 434, and a sound database module 421. The userinterface 427 preferably provides a connection to the requestingcomputer 401. The user interface 427 further facilitates communicationsbetween the requesting computer 401 and the system 414. In one preferredembodiment, the user interface 427 receives the request for access to acomputer function from the requesting computer 401. The user interface427 then manages the communications between the system 414 and therequesting computer 401 through the computer network 407. The userinterface 427 sends the validation test to the requesting computer 401.In some preferred embodiments the validation test is sent to therequesting computer for execution. Alternatively, the sounds from thevalidation test may be provided to the requesting computer 401 from theuser interface 427 through the computer network 407.

The generation module 427 prepares the validation test as describedabove, selecting validation and decoy sounds from the sound databasemodule 421. The answer confirmation module compares the inputs from therequesting computer 401 and the expected inputs from the validation testfile. If the inputs are within the parameters of the validation test,the requesting computer is authorized access to the computer function.If the inputs are not within the parameters of the validation test, therequesting computer is not allowed access to the computer function.

Having now fully set forth the preferred embodiments and certainmodifications of the concept underlying the present invention, variousother embodiments as well as certain variations and modifications of theembodiments herein shown and described will obviously occur to thoseskilled in the art upon becoming familiar with said underlying concept.It should be understood, therefore, that the invention may be practicedotherwise than as specifically set forth herein.

What is claimed is:
 1. A computer implemented method to authorize accessto a computer function, comprising the steps of: receiving a request toaccess a computer function from a requesting computer; generating acomputer generated validation test and an expected response, whereinsaid validation test comprises a series of sounds presented at variousintervals, wherein at least one sound in said series of sounds is avalidation sound; presenting said computer generated validation test tothe requesting computer; receiving an input from said requestingcomputer in response to the validation test presented to said requestingcomputer; determining whether the input corresponds to the expectedresponse; and allowing access to the computer function if the inputcorresponds to the expected response.
 2. The method of claim 1, whereinat least one sound in said series of sounds is a non-validation sound.3. The method of claim 1, wherein said validation sound is presentedmultiple times within said series of sounds.
 4. The method of claim 2,wherein said non-validation sound is presented multiple times withinsaid series of sounds.
 5. The method of claim 1, wherein the expectedresponse corresponds to at least one key stroke input recorded within aspecified period of time after a validation sound is presented.
 6. Themethod of claim 5, wherein the at least one key stroke is one key strokefor each instance a validation sound is presented.
 7. The method ofclaim 5, wherein a key stroke is selected from the group consisting of akeyboard entry, a tap on touch screen, and a mouse click.
 5. The methodof claim 1, wherein said presenting step comprises transmitting saidcomputer generated validation test to the requesting computer forexecution at the requesting computer.
 6. The method of claim 1, whereinsaid presenting step comprises presenting the output of the computergenerated validation test to the requesting computer where the computergenerated validation test is executed at a second computer.
 7. Themethod of claim 1, wherein said computer function is a website.
 8. Themethod of claim 1, wherein said requesting computer is selected from thegroup consisting of a mobile device, a mobile application, atelecommunications device, and a personal computer station.
 9. A systemfor authorizing access to a computer function, comprising a userinterface module, configured to manage communications between arequesting computer and the system; a validation test generation moduleconfigured to generate a validation test and an expected response,wherein said validation test comprises a series of sounds presented atvarious intervals, wherein at least one sound in said series of soundsis a validation sound; and an answer confirmation module, configured todetermine whether an input from said requesting computer corresponds tothe expected response and allowing access to the computer function;wherein the user interface module, the validation test module, and theanswer confirmation module are communicatively connected to each other.10. The system of claim 9, further comprising a sound database modulecomprising sound bites to be used by the validation test generationmodule.
 11. The system of claim 10, wherein the sound bites are arrangedby category.
 12. The system of claim 9: wherein the validation testgeneration module is configured to select validation and non-validationsounds.
 13. The system of claim 9, wherein the system is connected to acomputer network.